Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Systems Using Kubernetes by Brendan Burns

Author:Brendan Burns [Burns, Brendan]
Language: eng
Format: epub
Tags: Computers, Software Development & Engineering, General, Distributed Systems, Cloud Computing
ISBN: 9781098156350
Google: 9zjK0AEACAAJ
Publisher: O'Reilly Media
Published: 2024-12-30T23:00:00+00:00

The Basics of Leader Election

Imagine that there is a service Foo with three replicas: Foo-1, Foo-2, and Foo-3. There is also some object Bar that must only be “owned” by one of the replicas (e.g., Foo-1) at a time. Often this replica is called the leader, hence the term leader election used to describe the process of how this leader is selected as well as how a new leader is selected if that leader fails.

There are two ways to implement this leader election. This first is to implement a distributed consensus algorithm like Paxos or RAFT, but the complexity of these algorithms make them beyond the scope of this book and not worthwhile to implement. Implementing one of these algorithms is akin to implementing locks on top of assembly code compare-and-swap instructions. It’s an interesting exercise for an undergraduate computer science course, but it is not something that is generally worth doing in practice.

Fortunately, there are a large number of distributed key-value stores that have implemented such consensus algorithms for you. At a general level, these systems provide a replicated, reliable data store and the primitives necessary to build more complicated locking and election abstractions on top. Examples of these distributed stores include etcd, ZooKeeper, and Consul. The basic primitives that these systems provide is the ability to perform a compare-and-swap operation for a particular key. Compare-and-swap atomically writes a new value if the existing value matches the expected value. If the value doesn’t match, it returns false. If the value doesn’t exist and currentValue is not null, it returns an error. If you haven’t seen compare-and-swap before, it is basically an atomic operation that looks like this:

lock := sync.Mutex{} store := map[string]string{} func compareAndSwap(key, nextValue, currentValue string) (bool, error) { lock.Lock() defer lock.Unlock() _, containsKey := store[key] if !containsKey { if len(currentValue) == 0 { store[key] = nextValue return true, nil } return false, fmt.Errorf( "Expected value %s for key %s, but found empty", currentValue, key) } if store[key] == currentValue { store[key] = nextValue return true, nil } return false, nil }

In addition to compare-and-swap, the key-value stores allow you to set a time-to-live (TTL) for a key. Once the TTL expires, the key is set back to empty.

Put together, these functions are sufficient to implement a variety of distributed synchronization primitives.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.